Kapitel 5 Das Klassendesign (Teil 2)

In der Klasse Circle sind bisher drei Eigenschaften definiert, die den Zustand eines Objekts dieses Typs beschreiben:

XKoordinate

YKoordinate

Radius

5.1 Statische Klassenkomponenten 

Jede Instanz der Klasse Circle reserviert für ihre Daten einen eigenen Speicherbereich, der vollkommen unabhängig von den Daten anderer Objekte ist – selbst wenn diese typgleich sind. Auch alle bisher implementierten Methoden sind an Objekte gebunden, denn sie arbeiten mit den Zustandsdaten des Objekts.

Was ist aber, wenn Felder oder Methoden benötigt werden, die für alle Objekte der Klasse Circle gleichermaßen gültig sein sollen, also ohne feste Bindung an ein bestimmtes, konkretes Objekt? Stellen Sie sich vor, Sie beabsichtigten, in der Klasse Circle einen Zähler namens CountCircles zu implementieren, der die Aufgabe hat, die Gesamtanzahl der Kreisobjekte festzuhalten. Ein solcher Zähler entspricht der Forderung nach einer allgemeinen, objektunabhängigen Funktionalität.

Was jedoch benötigt wird, sind Felder und Methoden ohne Bindung an ein konkretes Objekt. Komponenten, die dieser Vorgabe entsprechen, werden auch als Klassenvariablen bzw. Klassenmethoden, oder – ganz allgemein – als statische Mitglieder bezeichnet.

5.1.1 Die Realisierung eines Objektzählers 

Der Objektzähler soll nun implementiert werden. Bitte beachten Sie, dass es sich um einen Objekt- und nicht um einen Referenzzähler handelt. Ein Objektzähler kennt die Gesamtanzahl aller konkreten Objekte, ein Referenzzähler hingegen verfolgt die Anzahl der Verweise auf ein bestimmtes Objekt.

Eine erste Idee könnte sein, die Circle-Klasse nach dem folgenden Schema zu implementieren:

Dieser triviale Lösungsansatz ist durchaus realisierbar, aber aus programmiertechnischer Sicht alles andere als optimal. Er bereitet nämlich Probleme, die bei genauerer Analyse zutage treten:

Verwaltet die Anwendung einige hundert Circle-Objekte, wäre das Feld CountCircles ebenso oft im Speicher vertreten, obwohl es immer denselben Wert hätte. Insbesondere bei Objekt-Arrays würden Speicherressourcen unnötig verschwendet.

Der Zähler muss erhöht werden, sobald ein weiteres Objekt dieses Typs erzeugt wird – und das nicht nur im neuen Objekt, sondern auch in jedem bereits existierenden. Die Folge ist eine Leistungseinbuße, die umso größer wird, je mehr Objekte gleichen Typs verwaltet werden.

Den Zähler als Instanzvariable zu definieren, ist demnach kein guter Ansatz und bei den beschriebenen Nachteilen nicht akzeptabel. Aber wo liegt der grundlegende Fehler der Überlegung?

Die Antwort auf die Frage ist recht einfach: Instanzvariablen sind objektgebunden. Um den Objektzähler zu realisieren, brauchen wir aber ein Feld, losgelöst von jedem konkreten Objekt, das nur in einer festen Bindung zur Klasse Circle steht. Der Objektzähler wäre damit als eine gemeinsame Eigenschaft aller Objekte dieses Typs zu betrachten.

Probleme dieser Art, allen typgleichen Objekten klassen-, aber nicht objektgebundene Elemente zur Verfügung zu stellen, werden von C# durch das Schlüsselwort static gelöst. Bezogen auf die Forderung nach einem Objektzähler, würde ein erster Ansatz zur Problemlösung wie folgt aussehen:

Die standardmäßige Sichtbarkeit statischer Komponenten ist private. Die Sichtbarkeit kann durch die Modifizierer public, protected, internal und private an die Anforderungen angepasst werden.

5.1.2 Zugriff auf statische Komponenten 

Klassenmethoden und -felder sind unabhängig von den Objekten einer Klasse. Daher ist es unzulässig, sie auf eine Objektreferenz aufzurufen, und führt sogar zu einem Kompilierfehler. Um eine Klassenvariable auszuwerten, reicht die Angabe des Typbezeichners. Ist in der Klasse Circle eine Klassenvariable CountCircles definiert, können Sie demnach mit

auf den Inhalt zugreifen.

Auch Methoden können static sein. Für den Aufruf einer Klassenmethode gilt wie für ein statisches Feld, dass vor dem Methodenbezeichner der Klassenname angegeben werden muss. Klassenmethoden wurden schon häufig in den Beispielcodes dieses Buches benutzt: Es sind die Methoden WriteLine und ReadLine, die von der Klasse Console bereitgestellt werden.

Sind in einer Klasse sowohl statische als auch objektbezogene Eigenschaften und Methoden definiert, unterliegt der wechselseitige Zugriff der beiden Elementtypen den folgenden zwei Regeln:

5.1.3 Statische Klassenvariable in der Klasse »Circle« 

Für statische Felder gelten dieselben Regeln der Datenkapselung wie für Instanzvariablen. Eine Klassenvariable wie CountCircles sollte daher in derselben Weise gekapselt werden, um nicht mit dem objektorientierten Paradigma zu brechen. Dazu wird sie private deklariert. Um den Zugriff von außerhalb sicherzustellen, implementieren wir in der Klasse Circle zusätzlich eine statische Eigenschaftsmethode. Damit eine Manipulation des Zählers von außerhalb unterbunden wird, muss die Eigenschaft durch Verzicht auf den set-Accessor schreibgeschützt sein.

Nun enthält die Circle-Klasse den angestrebten Objektzähler, der beliebig abgefragt werden kann. Allerdings ist die Klassendefinition noch unvollständig, denn es fehlt die Programmlogik, um den Zähler mit jeder neuen Objektinstanz zu erhöhen. Dazu bieten sich die Konstruktoren an. Hierbei nutzen wir wieder die Konstruktorverkettung und erhöhen den Objektzähler nur im parameterlosen Konstruktor, der aus den beiden anderen Initialisierungsroutinen aufgerufen wird:

Die Implementierung der Zählerreduzierung ist nicht ganz so einfach. Bekanntlich zeichnet sich die Zerstörung einer Instanz durch die .NET-Laufzeitumgebung dadurch aus, dass der Garbage Collector einen nicht deterministischen Dienst versieht. Mit anderen Worten: Es kann nicht vorhergesagt werden, wann er aktiv wird. Prinzipiell bieten sich daher zwei Lösungsansätze an:

Beide Einzellösungen sind unbefriedigend und der Preis, den wir für den automatischen Aufräummechanismus des Garbage Collectors zahlen müssen. Daher erscheint die Formulierung einer Synthese aus beiden Lösungsansätzen den Anforderungen noch am nächsten zu kommen:

Um den internen Zähler countCircles nicht zweimal herabzusetzen, ist zur Verfolgung des Freigabezustands eines Objekts die private Variable counterReduced deklariert. Bei einem ordnungsgemäßen Aufruf der Methode Dispose wird der Objektzähler reduziert und counterReduced auf true gesetzt. Der Code in der Dispose-Methode ist so entwickelt, dass ein versehentlich wiederholter Aufruf von Dispose kein weiteres Mal den Objektzähler reduziert. Ruft der Speicherbereinigungsmechanismus anschließend den Destruktor des Objekts auf, bleibt der Zähler unverändert, weil die Bedingung zur Ausführung der Anweisung nicht erfüllt ist. Vergisst der Client den Aufruf von Dispose, behält das Flag counterReduced seinen Initialisierungswert, und der Garbage Collector wird für die Aktualisierung des Objektzählers sorgen.

5.1.4 Klassenspezifische Methoden 

Neben den statischen Klasseneigenschaften können auch klassenbezogene Methoden definiert werden. Klassenmethoden sind unabhängig von einer bestimmten Klasseninstanz und werden ebenfalls mit dem Modifizierer static gekennzeichnet. Typischerweise werden statische Methoden da eingesetzt, wo nicht mit objektspezifischen Daten gearbeitet wird oder allgemein gültige Operationen angeboten werden sollen. Ein typischer Vertreter des .NET Frameworks ist die Klasse Math. In dieser sind alle Methoden statisch.

Methoden gelten als überladen, wenn sie sich in der Parameterliste unterscheiden. An dieser Regel ändert auch der Modifizierer static nichts. Wenn Sie also versuchen, die Methode

mit

zu überladen, wird die Kompilierung abgelehnt.

Weiter oben wurden zwei Regeln aufgestellt: Instanzmethoden können auf die statischen Mitglieder einer Klasse zugreifen, Klassenmethoden sind jedoch objektunabhängig und haben daher keinen Zugriff auf Instanzmember. Die Klassendefinition TestClass im folgenden Codebeispiel verdeutlicht diesen Sachverhalt. Die Instanzmethode EditVariable manipuliert sowohl die Instanzvariable lngVar als auch die Klassenvariable intVar, die Klassenmethode ClassMethod hat nur den Zugriff auf die allen Objekten der Klasse gemeinsame Eigenschaft intVar, nicht jedoch auf die objektspezifische lngVar.

5.1.5 Statische Methoden in der Klasse »Circle« 

Ehe wir die Klasse Circle um weitere Methoden ergänzen, wollen wir zunächst zwei Methoden zur Diskussion stellen, die bereits im Kapitel 4 entwickelt worden sind:

Beide Instanzmethoden haben allgemein gültigen Charakter, denn die erforderlichen Dateninformationen werden nicht aus dem Objekt bezogen, sondern über einen Parameter den Methoden mitgeteilt. Damit sind GetFlaeche und GetUmfang genau genommen objektunabhängig und sollten durch Ergänzung des Modifizierers static zu statischen Methoden erklärt werden:

Die Instanzmethode mit Rückgabe einer Objektreferenz

Darüber hinaus soll die Klasse Circle um Methoden ergänzt werden, die in der Lage sind, zwei Kreisobjekte miteinander zu vergleichen. Das Ergebnis des Vergleichs sei die Rückgabe der Referenz auf das größere der beiden Circle-Objekte. Haben beide Kreise denselben Radius, soll der Rückgabewert die Referenz auf das im ersten Argument aufgeführte Objekt sein. Wir werden dazu sowohl Instanz- als auch Klassenmethoden bereitstellen.

Fangen wir mit der Instanzmethode an. Der Code dazu lautet wie folgt:

Bigger prüft zuerst die Bedingung und benutzt dazu das Schlüsselwort

Beachten Sie, dass

nur für Instanzvariablen und Instanzmethoden zur Verfügung steht und bei statischen Klassenmitgliedern weder Sinn macht noch erlaubt ist. Die

Bedingung dürfte auch

lauten, um den Inhalt des Feldes radius des aktuellen Objekts auszuwerten. Die Angabe der this-Referenz ist im vorliegenden Fall nicht unbedingt notwendig, weil die Eindeutigkeit von radius auch ohne diese Angabe gewährleistet ist. Auf das Feld radius der übergebenen Referenz kreis ist der Zugriff trotz der private-Deklaration möglich, weil der Zugriff auf die privaten Member eines typgleichen Objekts gestattet ist.

Weniger empfehlenswert ist, über den Aufruf der beiden Eigenschaftsmethoden Radius die beiden Größen zu vergleichen, also:

Die Folge wäre der Aufruf des get-Accessors in der Eigenschaftsmethode. Das ist jedoch unnötig, weil das gekapselte Feld radius in jedem Fall einen gültigen Wert enthält.

Angenommen, die beiden Objektreferenzen Kreis1 und Kreis2 sind vom Typ Circle, könnten wir Bigger auf das Objekt Kreis1 wie folgt aufrufen:

Circle newCircle = Kreis1.Bigger(Kreis2)

Die Referenz auf das größere der beiden Objekte wird der Objektvariablen newCircle zugewiesen oder – falls die beiden Kreise gleich groß sind – entsprechend der Methodenimplementierung die Referenz auf das Objekt, in dessen Kontext der Aufruf der Methode erfolgt.

Bigger ist nicht in der Lage, einen Benutzer über eine gegebenenfalls vorliegende radielle Gleichheit zu informieren. Das soll eine Überladung sicherstellen. Da wir dann allerdings auch zwei Ergebnisse an den Aufrufer zurückliefern, müssen wir die Parameterliste um einen out-Parameter ergänzen.

Über equal wird dem Aufrufer bei ungleichen Radien false, ansonsten true zurückgeliefert. Die Prüfung der Radien beider Referenzen erfolgt über die vorher definierte einparametrige Bigger-Methode.

Wir wollen uns nun den Aufruf der zweiparametrigen Bigger-Methode an einem Codefragment ansehen.

Interessant ist die Auswertung des zweiten Parameters. In Main wird dazu die lokale Variable equality deklariert. Beim Methodenaufruf wird die Referenz auf diese Variable mit out an Bigger übergeben. Bigger-Methode schreibt das Ergebnis der Prüfung in den Parameter equal. Der aufrufende Code ist in der Lage, dieses über seine lokale Variable equality auszuwerten.

Klassenmethoden mit Rückgabe einer Objektreferenz

Dasselbe Verhalten sollen jetzt auch noch zwei Klassenmethoden aufweisen. Weil der Aufruf einer Klassenmethode immer auf dem Klassennamen erfolgt, müssen die beiden zu vergleichenden Circle-Objekte an die Parameterliste übergeben werden.

Größenvergleich mit booleschem Rückgabewert

Alle bisher implementierten Bigger-Methoden liefern dem Aufrufer jeweils die Referenz auf ein Circle-Objekt zurück. Wenn der Vergleich in einer Kontrollstruktur wie der bedingten Anweisung erfolgt, ist eher ein boolescher Rückgabewert von Interesse. Nehmen wir an, wir wollen nur wissen, ob der Radius einer Referenz größer ist als der Radius einer zweiten Referenz, und nehmen wir weiter an, dass die Methode, die einen bool liefert, IsBigger heißt und als Klassenmethode definiert ist. Dann könnte mit der Anweisung

if(Circle.IsBigger(Kreis1, Kreis2))...

der einfache Vergleich erfolgen.

Um diese Bedingungsprüfung durchführen zu können, wollen wir jetzt IsBigger implementieren. Wir legen dabei fest, dass der Methodenaufruf true zurückliefern soll, falls der Radius des Kreises des ersten Parameters größer oder gleich dem Kreis des zweiten Parameters ist. Das entspricht der Bedingung

Kreis1.Radius >= Kreis2.Radius

Mit dieser Vorgabe sieht die statische Methode wie folgt aus:

Selbstverständlich bestünde auch die Möglichkeit, zusätzlich eine Instanzmethode namens IsBigger anzubieten. Der Programmcode unterscheidet sich aber nur geringfügig von dem der hier gezeigten statischen Variante und trägt nicht weiter zum Verständnis bei. Daher wird an dieser Stelle darauf verzichtet.

5.1.6 Statische Klasseninitialisierer 

Nach dem aktuellen Stand enthält die Klasse Circle mehrere Instanzfelder und eine Klassenvariable:

Klassen- und Instanzvariablen werden zu unterschiedlichen Zeitpunkten initialisiert. Dabei gilt die folgende Regel:

Praktisch bedeutet das, dass uns bereits mit

ein Ergebnis angezeigt wird, ohne dass vorher ein Objekt dieses Typs erzeugt worden ist, während andererseits eine Instanzvariable grundsätzlich immer die Existenz eines konkreten Objekts voraussetzt.

Bei der Instanziierung einer Klasse wird ein Konstruktor aufgerufen. Auf Klassenbasis gibt es dazu ein Pendant, das als statischer Konstruktor oder statischer Initialisierer bezeichnet wird. Der statische Konstruktor ist eine an die Klasse gebundene Methode, die nur auf die statischen Mitglieder der Klasse Zugriff hat.

Der statische Konstruktor einer Klasse wird aufgerufen, bevor die erste Instanz erstellt wird oder der erste Zugriff auf ein statisches Klassenmitglied erfolgt. Die Definition eines statischen Konstruktors sieht folgendermaßen aus:

Beachten Sie, dass ein statischer Konstruktor, ähnlich wie der Destruktor, keinen Zugriffsmodifizierer akzeptiert. Da ein statischer Konstruktor automatisch aufgerufen wird und niemals direkt, macht eine Parameterliste keinen Sinn – die Klammern bleiben grundsätzlich leer.

Das folgende Codefragment zeigt den statischen Initialisierer einer fiktiven Klasse ClassA, welcher der Klassenvariablen str einen Wert zuweist.

Selbstverständlich könnten wir denselben Effekt erzielen, wenn wir die statische Variable direkt mit

initialisieren würden. Der statische Konstruktor bietet sich eher dazu an, komplexere Initialisierungen vorzunehmen. Dabei könnte es sich um das Auslesen von Dateien oder auch um die Initialisierung statischer Arrays handeln, wie das folgende Beispiel zeigt:

Das Array myArr in der Klasse ClassA wird im statischen Konstruktor mit Werten zwischen 0 und 100 initialisiert, die nach dem Zufallsprinzip der Klasse Random gebildet werden. Zur Bestätigung erfolgt die Ausgabe des Array-Inhalts an der Konsole.

Aufrufreihenfolge der Konstruktoren

Statische Klasseninitialisierer und Konstruktoren sind sich in der Funktionsweise ähnlich. Während Klasseninitialisierer Klassendaten bereitstellen, versorgen Konstruktoren die objektspezifischen Felder mit Daten. Sobald Sie eine Objektvariable deklarieren, wird, soweit implementiert, der statische Konstruktor ausgeführt und erst danach der Konstruktor. Im Bedarfsfall dürfen Sie also im Konstruktor Code implementieren, der die vorhergehende Initialisierung der statischen Klassenmitglieder voraussetzt.

5.1.7 Statische Klassen 

Es gibt Klassen, die nur statische Mitglieder enthalten. Meistens handelt es sich dabei um Klassen, die allgemein gültige Operationen bereitstellen. Im .NET Framework gibt es davon einige, System.Math gehört auch dazu. Typischerweise sind solche Klassen nicht instanziierbar, weil ein Objekt einer solchen Klasse funktionslos und damit letztendlich auch sinnlos ist. Nicht instanziierbare Klassen haben darüber hinaus einen private definierten, parameterlosen Konstruktor, um die Instanziierung von vornherein unmöglich zu machen.

Mit der Version 2.0 des .NET Frameworks wird die Entwicklung von Klassen, die nur statische Mitglieder bereitstellen, ein wenig einfacher, zumindest jedoch offensichtlicher. Der Modizierer static kann nun auch vor dem Schlüsselwort class angegeben werden, z.B.:

Geben Sie static als Modifizierer einer Klasse an, müssen Sie die folgenden Punkte beachten:

Statische Klassen dürfen nur statische Klassenmitglieder veröffentlichen. Der Modizierer static ist auch bei den Membern anzugeben.

Statische Klassen enthalten keine Konstruktoren und können deshalb auch nicht instanziiert werden. Der parameterlose Konstruktor ist implizit private.

Statische Klassen können nicht abgeleitet werden.

Der Aufruf statischer Klassen erfolgt ebenfalls unter Angabe des Klassenbezeichners, z.B.:

5.1.8 Zusammenfassung 

Statische Klassenkomponenten, gekennzeichnet durch den Modifizierer static, sind nicht an ein konkretes Objekt gebunden. Es gibt sowohl statische Felder als auch statische Eigenschaften und Methoden. Statische Klassenmitglieder werden über die Angabe des Klassennamens angesprochen.

Ein statisches Feld existiert nur einmal im Speicher, unabhängig davon, wie viele Klasseninstanzen erzeugt werden.

Klassenmethoden können weder Instanzvariablen manipulieren noch Instanzmethoden aufrufen. Andererseits haben Instanzmethoden die Möglichkeit, sowohl auf statische Felder zuzugreifen als auch statische Methoden auszuführen.

Die this-Referenz steht in statischen Methoden nicht zur Verfügung.

Klassenvariablen werden initialisiert, sobald der erste Zugriff auf die Klasse erfolgt. Die Initialisierung der Klassenvariablen kann über den statischen Konstruktor erfolgen. Dieser wird automatisch aufgerufen, hat keinen Zugriffsmodifizierer und grundsätzlich eine leere Parameterliste.

Wird erstmalig das Objekt eines Typs erzeugt, wird zuerst der statische Initialisierer aufgerufen und danach der Konstruktor zur Initialisierung der Objektdaten.

Statische Klassen werden in der Klassendefinition um den Modifizierer static ergänzt. Eine statische Klasse kann weder instanziiert noch abgeleitet werden und hat nur statische Klassenmitglieder.